home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 14 / CU Amiga Magazine's Super CD-ROM 14 (1997)(EMAP Images)(GB)(Track 1 of 3)[!][issue 1997-09].iso / CUCD / Programming / AMOS / AMOSList-0697 / AMOSLIST / text0226.txt < prev    next >
Encoding:
Text File  |  1997-07-03  |  2.6 KB  |  88 lines

  1. On 24-Jun-97, Rune J. Keller wrote:
  2.  
  3.  
  4. >A couple of my friends from school run a PC-network where
  5. >they're usually playing a game like Quake. Now, one of them has a
  6. >P-75 and run the game with about 15fps. Another has a P-200MMX
  7. >and can easily run 30fps. However the game itself runs with the
  8. >same speed on both computers...
  9.  
  10.    Actually, in a case like this where you have a VERY fast machine
  11.    linked with a slow machine, the processing is sometimes divided
  12.    up between the two (or more) machines based on their speed.
  13.  
  14.    So, the P200MMX machine may be processing 80% of all the
  15.    games control-code and passing the processed data to the P75
  16.    machine which is spending the majority of it's time retrieving
  17.    that data and refreshing the display...
  18.  
  19.    Obviously, you need a local-link between the machines as using
  20.    this over the Internet would be a just a bit slow... HA!HA!
  21.  
  22.  
  23. >To solve the problem you could check the speed of the machine
  24. >in the beginning of the game and according to this value change
  25. >the speed of the monsters.
  26.  
  27.    You could double the animation frames for every object 
  28.    targeting the fast machines from the start.
  29.  
  30.    If the machine is slow, set the anim-step to 2 and double the
  31.    x/y velocities of every object.
  32.  
  33.    This would effectively make the game run the same speed. The
  34.    difference being that the 50fps version would be twice as
  35.    smooth due to the doubling of the number of anim-frames...
  36.  
  37.    Or, if you wanted the easy way you could just duplicate each of
  38.    the current frames, so DRAGONHEADFACINGLEFT elements (0)&(1)
  39.    both equal the same image. Again, simply adjust the ANIMSTEP
  40.    at the start based on CPU power...
  41.  
  42. >Has anybody else solved this problem in a better way?
  43.  
  44.    I don't know if I'd say it's better, but the EASY way is just to place
  45.    a little timer check in your main-loop:
  46.  
  47.    Repeat
  48.  
  49.       Timer=0       : Rem  Simply reset the Timer at start of loop...
  50.  
  51.       Bob Clear
  52.       DO_ALL_THE_MAGIC
  53.       Bob Draw
  54.  
  55.       Repeat : Until Timer : Rem Make sure at least 1 Vbl has passed...
  56.  
  57.       Screen Swap : Wait Vbl
  58.  
  59.    Until STAGEOVER
  60.  
  61.  
  62.    That's fast and easy. The game can't run faster than 25/30fps
  63.    and it doesn't slow-down the underpowered machines.
  64.  
  65.    This is the method I will be using in the Shooter-stage so the final
  66.    version will run at 25/30 fps on all machines (except stock A500
  67.    that is)...
  68.  
  69.    Speaking of the Shooter-stage, I sent the new demo to Mr. G, so
  70.    it should be on the web-page by now.
  71.  
  72.    
  73.    Any of you guys using 50MHz Amigas, PLEASE let me know how the
  74.    demo performs on your machines.
  75.       
  76.    Should easily hit 50/60 fps, but I'd like to be sure...
  77.  
  78.  
  79.  
  80.       Take care,
  81.  
  82.          Garfield
  83.  
  84.  
  85.  
  86.  
  87.  
  88.